[Previous] [Next] [Index]
[Thread]
Re: SECURITY ALERT: Password protection bug in Netscape 2.0b3
Lincoln and Gerard,
Let me first clarify that Netscape Navigator does not save the passwords
used to access a protected document in any hidden files.
Second the problem you have noticed is indeed a bug in the 2.0 beta
versions of Netscape Navigator. The bug is that when a user gets an
access denied response from a server (401 HTTP response) when requesting
a protected document the Navigator means to delete the cached copy of
that document, but the current beta versions do not. Thus, when a user
hits the "back" button the program pulls the document out of the cache.
Not intended behavior.
This bug has been confirmed internally and will be fixed before the
final version of 2.0.
thanks,
jeff
ps. I have passed on your names and descriptions of the bug to our Bugs
Bounty evaluators for possible rewards.
hickey@ctron.com wrote:
>
> > I believe you're right. Netscape is cacheing the protected document to
> > disk and then returning it on subsequent sessions without requiring
> > reauthentication by the user. This is still a major uh-oh, but not nearly
> > as bad as my first hypothesis that Netscape was storing passwords to disk.
> >
> > Lincoln
> >
>
> This is a bug that we found a little while ago. It was not present in version
> 1.X, but it was introduced with the 2.0 code.
>
> There are two versions of this bug that is really the same one.
>
> 1. If you have your "verify document" set to once per session, then
> you can cancel on an authorization attempt, go to an unprotected
> URL and use the back button to get the text. The images on the
> page are attempted to be retrieved and produce authorization
> attempts.
>
> 2. The second is the one scenerio is the one that Lincoln has
> witnessed. When the "verify document" is set to never, the
> browser can be tricked into getting the document out of the
> cache without authenication.
>
> If I remember correctly, the browser works as expected when you have the
> "verify document" set to everytime. Essentially everytime you attempt to
> get the document, the browser will do a HEAD on the document, and the server
> will force the authentication.
>
> Clearly, this is a bug in the browser, but I think that it is somewhat
> understandable it being overlooked by the programmers at Netscape.
> --
> Gerard Hickey, hickey@ctron.com, +1 603 337 7391/+1 603 337 7784 (fax)
> Cabletron Systems, 36 Industrial Way, Rochester, NH 03867
> ======================================================================
> Cabletron Systems Webmaster (webmaster@ctron.com)
> http://www.ctron.com/~hickey/
--
jeff@netscape.com | tel: 415-528-2617 | fax: 415-528-4120
Netscape: 501 East Middlefield Rd Mountain View, CA 94043
about:jeff -- "speakin for just me and no one else" --
Follow-Ups:
References: